url: speed up WHATWG URL parsing - #65361

Speeds up new URL() / URL.parse() on the common path: already-serialized ASCII hrefs.

The binding currently always:

1. Copies the V8 string into a UTF-8 buffer (Utf8Value)
2. Parses with Ada
3. Allocates a new V8 string from href, even when it is byte-identical to the input

Typical URLs (https://example.com/path, the whatwg-url-parse benchmark corpus) are one-byte ASCII and already in serialized form. This change:

• Parses one-byte ASCII inputs in place via v8::String::ValueView (no UTF-8 copy)
• Returns the original V8 string when href == input (no second string allocation)
• Avoids copying the base URL into a temporary std::string just to parse it
• Applies the same in-place parse to update() (setters re-parse an already-serialized href)
• Delays URLContext allocation until parse finishes, and initializes it in one shot from urlComponents
• Skips `${input}` when the value is already a string

Non-ASCII inputs still go through Utf8Value. Those results are never reused as the original string, because UTF-8 conversion may replace unpaired surrogates.

Benchmark

Same machine, Release build, benchmark/url/whatwg-url-parse.js e=12. Repeated runs:

dot (needs path normalization, so a new href string) is unchanged.

Review follow-up

• reuse_input defaults to nullptr. Base-URL parse and update() omit it so we skip the O(n) href == input compare when the original V8 string will not be reused.

Tests

• test/parallel/test-whatwg-url-*.js and test-url-*.js: 54 pass, 1 skip
• WPT url: 5107 pass, 0 unexpected failures
• New test/parallel/test-whatwg-url-parse-fast-path.js covers already-serialized ASCII hrefs, trailing-slash and dot-segment normalization, base resolution, non-string input, invalid input, unpaired surrogates, IDN, and setters

Assisted-by: Cursor